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DETAILED ACTION 

This action is responsive to the Amendment/Arguments filed on December 17, 2007. Claims 1- 
49 are pending. 

Response to Arguments 

1 . Applicant's arguments with respect to Drawing Objections due to minor informalities 
have been fully considered and are persuasive. The objection to Figure 3 has been withdrawn. 

2. Applicant's arguments with respect to Drawing Objections under 37 CFR 1.84(p)(5) have 
been fully considered and are persuasive. The objection to Figure 4 has been withdrawn. 

3. Applicant's arguments with respect to Claims 1-47 have been considered but are moot in 
view of the new ground(s) of rejection. 

Claim Rejections - 35 USC § 102 

4. The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

5. Claims 1, 10, 27, 36 and 48-49 are rejected under 35 U.S.C. 102(b) as being anticipated 
by Applicant's Admitted Prior Art (AAPA). 
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6. As to Claims 1 and 27, AAPA discloses for use with a node, a method and elements 
(referenced hereinafter as the method) comprising: 

a) accepting status information from at least two different protocols (AAPA; Figure 1 and 
paragraphs 4-7, 15, and 25, discloses accepting status information from two different protocols); 

b) composing a message including the status information (AAPA; Figure 1 and 
paragraphs 4-7, 15, and 25, discloses composing a message including status information with 
respect to a protocol); and 

c) sending the message towards a neighbor node (AAPA; Figure 1 and paragraphs 4-7, 
15, and 25, discloses sending the message to a neighbor node). 

7. As to Claims 10 and 36, AAPA discloses each and every limitation of Claims 1 and 27. 
AAPA further discloses wherein the neighbor node has at least one protocol peering with at least 
one of the at least two protocols (AAPA; Figure 1 and paragraphs 4-7, 15, and 25, discloses the 
neighbor node has at least one protocol peering with one of the protocols in the first node). 

8. As to Claim 48, AAPA discloses each and every limitation of Claim 1 . AAPA further 
discloses wherein the status information is local protocol status information (AAPA; Figure 1 
and paragraphs 4-7, 15, and 25, discloses the status information is local protocol status 
information). 

9. As to Claim 49, AAPA discloses each and every limitation of Claim 1 . AAPA further 
discloses wherein the status information is local status information and wherein each of the at 
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least two different protocols is bring run locally on the node (AAPA; Figure 1 and paragraphs 4- 
7, 15, and 25, discloses the status information is local protocol status information and each of the 
two different protocols is being run locally on the node). 



10. Claims 1, 10, 19, 27, 36, 45, and 48-49 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Internetworking with TCP/IP to Comer. 

11. As to Claims 1 and 27, Comer discloses for use with a node, a method and elements 
(referenced hereinafter as the method) comprising: 

a) accepting status information from at least two different protocols (Comer; 15.10 BGP 
Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses determining 
at a first node status information for both BGP and TCP protocols); 

b) composing a message including the status information (Comer; Figure 15.10 BGP 
Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses composing a 
keepalive message including the status information); and 

c) sending the message towards a neighbor node (Comer; 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses sending the keepalive message 
to neighbor second node). 

12. As to Claims 10 and 36, Comer discloses each and every limitation of Claims 1 and 27. 
Comer further discloses wherein the neighbor node has at least one protocol peering with at least 
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one of the at least two protocols (Comer; 15.10 BGP Functionality and Message Types and 15.16 
BGP KEEP ALIVE Message, discloses the neighbor node has at least one protocol peering with 
one of the protocols in the first node). 

13. As to Claims 19 and 45, Comer discloses a method and a system (hereinafter referred to 
as the method) for monitoring liveness of multiple protocols, the method comprising: 

a) determining, at a first node, status information for at least two different protocols 
(Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE Message, 
discloses determining at a first node status information for both BGP and TCP protocols); 

b) sending, from the first node, a message including the determined status information to 
a second node (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEPALIVE Message, discloses sending a keepalive message indicating the status of the 
protocols to a second node); 

c) receiving, at the second node, the message (Comer; 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses receiving the message at the 
second node); and 

d) updating, by the second node, first node protocol status information using the message 
(Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE Message, 
discloses updating TCP and BGP connection status information using the message). 

14. As to Claim 48, Comer discloses each and every limitation of Claim 1 . Comer further 
discloses wherein the status information is local protocol status information (Comer; 15.10 BGP 
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Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses the status 
information is local protocol status information). 

15. As to Claim 49, Comer discloses each and every limitation of Claim 1 . Comer further 
discloses wherein the status information is local status information and wherein each of the at 
least two different protocols is bring run locally on the node (Comer; 15.10 BGP Functionality 
and Message Types and 15.16 BGP KEEPALIVE Message, discloses the status information is 
local protocol status information and each of the two different protocols is being run locally on 
the node). 

Claim Rejections - 35 USC §103 

16. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

17. Claims 2-9, 11, 28-35, and 37 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over AAPA as applied to Claim 1 above, and further in view of Internet-Draft Fast Liveness 
Protocol to Sandick et al. (hereinafter "Sandick") (IDS submitted on July 12, 2004). 
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18. As to Claims 2 and 28, AAPA discloses each and every limitation of Claims 1 and 27. 
AAPA does not explicitly disclose, however Sandick discloses 

d) maintaining a first timer for tracking a send time interval, wherein the acts of composing a 
message and sending the message are performed after expiration of the first timer (Sandick; 4.2 
Parameters and 5.3 Finite State Machine for Hello Message Exchange, discloses maintaining a 
Hellolnterval timer to determine how often FLIP hello messages should be sent); and 

e) restarting the first timer after the message is sent (Sandick; 4.2 Parameters and 5.3 Finite state 
machine for Hello Message Exchange, discloses restarting the timer after the message is sent). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending a message, as disclosed by AAPA, to include a send 
time interval and associated first timer, as disclosed by Sandick, in order to facilitate neighbor or 
peer protocol failure detection (Sandick; Abstract and 4.2 Parameters). 

19. As to Claims 3 and 29, AAPA discloses each and every limitation of Claims 1 and 27. 
AAPA does not explicitly disclose, however Sandick discloses wherein the message further 
includes a dead time interval, and wherein the send time interval is less than the dead time 
interval (Sandick; 4.2 Parameters and 5.3 Finite State Machine for Hello Message Exchange, 
discloses a PeerDeadlnterval, included in a FLIP Advertisement, that is larger than the 
Hellolnterval and that indicates how long a device should wait from the last Hello before 
declaring a neighbor failure). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by AAPA, to include a dead time interval which is 
greater than the send time interval, as disclosed by Sandick, in order to facilitate neighbor or peer 
protocol failure detection (Sandick; Abstract and 4.2 Parameters). 

20. As to Claims 4 and 30, AAPA discloses each and every limitation of Claims 1 and 27. 
AAPA does not explicitly disclose, however Sandick discloses wherein the message further 
includes a dead time interval, and wherein the send time interval is no more than one third of the 
dead time interval (Sandick; 4.2 Parameters and 5.3 Finite State Machine for Hello Message 
Exchange, discloses a PeerDeadlnterval, included in the FLIP Advertisement, that is at least 3 
times the value of the Hellolnterval). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by AAPA, to include a dead time interval which is 
greater than 3 times the send time interval, as disclosed by Sandick, in order to facilitate 
neighbor or peer protocol failure detection and prevent erroneous declaration of a peer protocol 
failure in a situation where a message was lost in transmission (Sandick; Abstract and 4.2 
Parameters). 

21. As to Claims 5 and 3 1 , AAPA discloses each and every limitation of Claims 1 and 27. 
AAPA does not explicitly disclose, however Sandick discloses wherein the send time interval is 
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less than one second (Sandick; 7.2 Hellolnterval, discloses the Hellolnterval default value is 3 
ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending a message, as disclosed by AAPA, to include a send 
time interval that is less than one second, as disclosed by Sandick, in order to facilitate neighbor 
or peer protocol failure detection and expedite the detection and thereby the correction of a 
failure (Sandick; Abstract). 

22. As to Claims 6 and 32, AAPA discloses each and every limitation of Claims 1 and 27. 
AAPA does not explicitly disclose, however Sandick discloses wherein the send time interval is 
less than 100 msec (Sandick; 7.2 Hellolnterval, discloses the Hellolnterval default value is 3 ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending a message, as disclosed by AAPA, to include a send 
time interval that is less than 100 ms, as disclosed by Sandick, in order to facilitate neighbor or 
peer protocol failure detection and expedite the detection and thereby the correction of a failure 
(Sandick; Abstract). 

23. As to Claims 7 and 33, AAPA discloses each and every limitation of Claims 1 and 27. 
AAPA does not explicitly disclose, however Sandick discloses wherein the message further 
includes a dead time interval (Sandick; 4.2 Parameters, discloses a PeerDeadlnterval included in 
the FLIP Advertisement). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by AAPA, to include a dead time interval, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection (Sandick; 
Abstract and 4.2 Parameters). 

24. As to Claims 8 and 34, AAPA discloses each and every limitation of Claims 1 and 27. 
AAPA does not explicitly disclose, however Sandick discloses wherein the act of sending the 
message includes providing the message in an Internet protocol packet (Sandick; Abstract and 
Introduction, discloses sending a message using Internet protocol). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify sending a message, as disclosed by AAPA, to include providing the 
message in an Internet protocol packet, as disclosed by Sandick, in order to facilitate neighbor or 
peer protocol failure detection in IP networks (Sandick; Abstract and Introduction). 

25. As to Claims 9 and 35, AAPA and Sandick in combination disclose each and every 
limitation of claims 8 and 34. Sandick further discloses wherein the act of sending the message 
towards the neighbor node includes setting a destination address in the Internet protocol packet 
to a multicast address associated with routers that support aggregated protocol liveness (Sandick; 
4. 1 Neighbor Discovery, 4.2 Parameters, and 4.6 Finite State Machine for Neighbor Adjacency, 
discloses the sending the message as a multicast message to a neighbor node by setting the 
destination address to a multicast address). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify sending a message in an IP packet, as disclosed by AAPA, as modified by 
Sandick, to include setting a destination address in the Internet protocol packet to a multicast 
address, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection 
on a subnet (Sandick; 4.1 Neighbor Discovery, 4.2 Parameters, and 4.6 Finite State Machine for 
Neighbor Adjacency). 

26. As to Claims 1 1 and 37, AAPA discloses each and every limitation of Claims 1 and 27. 
AAPA does not explicitly disclose, however Sandick discloses wherein the status information 
includes a protocol state selected from a group of protocols states consisting of (A) protocol up, 
(B) protocol down, (C) protocol not reporting, and (D) protocol restarting (Sandick; Abstract, 
Introduction, and 4.2 Parameters, discloses that status of the protocol is indicated by the ability 
of the node or the protocol to send messages. A peer protocol receiving the message indicates 
that the protocol state is up, and failure to receive the message indicates the protocol state is 
down). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information, as disclosed by AAPA, to include an indication of 
protocol state, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection in IP networks (Sandick; Abstract and Introduction). 
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27. Claims 2-9, 11-15, 20-26, 28-35, 37-41, and 46-47, are rejected under 35 U.S.C. 103(a) 
as being unpatentable over Comer as applied to Claim 1 above, and further in view of Sandick. 

28. As to Claims 2 and 28, Comer discloses each and every limitation of Claims 1 and 27. 
Comer does not explicitly disclose, however Sandick discloses 

d) maintaining a first timer for tracking a send time interval, wherein the acts of composing a 
message and sending the message are performed after expiration of the first timer (Sandick; 4.2 
Parameters and 5.3 Finite State Machine for Hello Message Exchange, discloses maintaining a 
Hellolnterval timer to determine how often FLIP hello messages should be sent); and 

e) restarting the first timer after the message is sent (Sandick; 4.2 Parameters and 5.3 Finite state 
machine for Hello Message Exchange, discloses restarting the timer after the message is sent). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending a message, as disclosed by Comer, to include a send 
time interval and associated first timer, as disclosed by Sandick, in order to facilitate neighbor or 
peer protocol failure detection (Sandick; Abstract and 4.2 Parameters). 

29. As to Claims 3 and 29, Comer discloses each and every limitation of Claims 1 and 27. 
Comer does not explicitly disclose, however Sandick discloses wherein the message further 
includes a dead time interval, and wherein the send time interval is less than the dead time 
interval (Sandick; 4.2 Parameters and 5.3 Finite State Machine for Hello Message Exchange, 
discloses a PeerDeadlnterval, included in a FLIP Advertisement, that is larger than the 
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Hellolnterval and that indicates how long a device should wait from the last Hello before 
declaring a neighbor failure). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by Comer, to include a dead time interval which is 
greater than the send time interval, as disclosed by Sandick, in order to facilitate neighbor or peer 
protocol failure detection (Sandick; Abstract and 4.2 Parameters). 

30. As to Claims 4 and 30, Comer discloses each and every limitation of Claims 1 and 27. 
Comer does not explicitly disclose, however Sandick discloses wherein the message further 
includes a dead time interval, and wherein the send time interval is no more than one third of the 
dead time interval (Sandick; 4.2 Parameters and 5.3 Finite State Machine for Hello Message 
Exchange, discloses a PeerDeadlnterval, included in the FLIP Advertisement, that is at least 3 
times the value of the Hellolnterval). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by Comer, to include a dead time interval which is 
greater than 3 times the send time interval, as disclosed by Sandick, in order to facilitate 
neighbor or peer protocol failure detection and prevent erroneous declaration of a peer protocol 
failure in a situation where a message was lost in transmission (Sandick; Abstract and 4.2 
Parameters). 
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31. As to Claims 5 and 3 1 , Comer discloses each and every limitation of Claims 1 and 27. 
Comer does not explicitly disclose, however Sandick discloses wherein the send time interval is 
less than one second (Sandick; 7.2 Hellolnterval, discloses the Hellolnterval default value is 3 
ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending a message, as disclosed by Comer, to include a send 
time interval that is less than one second, as disclosed by Sandick, in order to facilitate neighbor 
or peer protocol failure detection and expedite the detection and thereby the correction of a 
failure (Sandick; Abstract). 

32. As to Claims 6 and 32, Comer discloses each and every limitation of Claims 1 and 27. 
Comer does not explicitly disclose, however Sandick discloses wherein the send time interval is 
less than 100 msec (Sandick; 7.2 Hellolnterval, discloses the Hellolnterval default value is 3 ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending a message, as disclosed by Comer, to include a send 
time interval that is less than 100 ms, as disclosed by Sandick, in order to facilitate neighbor or 
peer protocol failure detection and expedite the detection and thereby the correction of a failure 
(Sandick; Abstract). 

33. As to Claims 7 and 33, Comer discloses each and every limitation of Claims 1 and 27. 
Comer does not explicitly disclose, however Sandick discloses wherein the message further 
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includes a dead time interval (Sandick; 4.2 Parameters, discloses a PeerDeadlnterval included in 
the FLIP Advertisement). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by Comer, to include a dead time interval, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection (Sandick; 
Abstract and 4.2 Parameters). 

34. As to Claims 8 and 34, Comer discloses each and every limitation of Claims 1 and 27. 
Comer does not explicitly disclose, however Sandick discloses wherein the act of sending the 
message includes providing the message in an Internet protocol packet (Sandick; Abstract and 
Introduction, discloses sending a message using Internet protocol). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify sending a message, as disclosed by Comer, to include providing the 
message in an Internet protocol packet, as disclosed by Sandick, in order to facilitate neighbor or 
peer protocol failure detection in IP networks (Sandick; Abstract and Introduction). 

35. As to Claims 9 and 35, Comer and Sandick in combination disclose each and every 
limitation of claims 8 and 34. Sandick further discloses wherein the act of sending the message 
towards the neighbor node includes setting a destination address in the Internet protocol packet 
to a multicast address associated with routers that support aggregated protocol liveness (Sandick; 
4. 1 Neighbor Discovery, 4.2 Parameters, and 4.6 Finite State Machine for Neighbor Adjacency, 
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discloses the sending the message as a multicast message to a neighbor node by setting the 
destination address to a multicast address). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify sending a message in an IP packet, as disclosed by Comer, as modified by 
Sandick, to include setting a destination address in the Internet protocol packet to a multicast 
address, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection 
on a subnet (Sandick; 4.1 Neighbor Discovery, 4.2 Parameters, and 4.6 Finite State Machine for 
Neighbor Adjacency). 

36. As to Claims 1 1 and 37, Comer discloses each and every limitation of Claims 1 and 27. 
Comer does not explicitly disclose, however Sandick discloses wherein the status information 
includes a protocol state selected from a group of protocols states consisting of (A) protocol up, 
(B) protocol down, (C) protocol not reporting, and (D) protocol restarting (Sandick; Abstract, 
Introduction, and 4.2 Parameters, discloses that status of the protocol is indicated by the ability 
of the node or the protocol to send messages. A peer protocol receiving the message indicates 
that the protocol state is up, and failure to receive the message indicates the protocol state is 
down). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information, as disclosed by Comer, to include an indication of 
protocol state, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection in IP networks (Sandick; Abstract and Introduction). 
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37. As to Claims 12 and 38, Comer discloses for use with a node, a method and elements 
(referenced hereinafter as the method) comprising: 

a) receiving a message including 

i) for a first set of at least two different protocols of a neighbor node, status 
information for each of the protocols of the first set (Comer; 15.10 BGP Functionality 
and Message Types and 15.16 BGP KEEP ALIVE Message, discloses receiving the BGP 
keepalive message including status information about the neighbor BGP and TCP), and 

Comer does not explicitly disclose, however Sandick discloses ii) a time interval 
(Sandick; 4.2 Parameters, PeerDeadlnterval included in the FLIP Advertisement); and 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify a message, as disclosed by Comer, to include a dead time 
interval, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection (Sandick; Abstract and 4.2 Parameters). 

Comer further discloses b) updating neighbor node protocol status information using the 
message (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE 
Message, discloses updating TCP and BGP connection status information using the message). 

38. As to Claims 13 and 39, Comer and Sandick in combination disclose each and every 
limitation of Claims 12 and 38. 
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Sandick further discloses wherein the act of updating neighbor node protocol status 
information includes 

i) setting a first timer to the time interval and starting the first timer (Sandick; 5.3 Finite 
State Machine for Hello Message Exchange, discloses a setting a PeerDeadlnterval timer to a 
PeerDeadlnterval), 

Comer further discloses ii) if the first timer expires, setting the status of each of the 
protocols of the neighbor node to down (Comer; 15.10 BGP Functionality and Message Types 
and 15.16 BGP KEEPALIVE Message, discloses setting the status of the BGP and TCP 
protocols of the neighbor node to down when the timer expires) (Sandick; 5.3 Finite State 
Machine for Hello Message Exchange, discloses setting the status of a peer protocol of the 
neighbor node to down when the timer expires), and 

Comer further discloses iii) if a further message, sourced from the neighbor node, and 
including 

A) for a second set of at least two protocols, status information for each of the 

protocols of the second set, and 

[...] 

is received then, [. . .Jrestarting the first timer (Comer; 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses restarting the timer in response 
to receiving a further keepalive). 

Comer does not explicitly disclose, however Sandick discloses B) a new time interval and 
resetting the first timer to the new time interval (Sandick; 4.2 Parameters and 5.3 Finite State 
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Machine for Hello Message Exchange, discloses including a PeerDeadlnterval in the FLIP 
Advertisements, and resetting the PeerDeadlnterval timer to the time interval that is received in 
the message). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a further message, as disclosed by Comer, to include a dead time interval, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection (Sandick; 
Abstract and 4.2 Parameters). 

39. As to Claims 14 and 40, Comer and Sandick in combination disclose each and every 
limitation of Claims 13 and 39. Sandick further discloses wherein each of the time interval and 
the new time interval is less than one second (Sandick; 4.2 Parameters, 5.3 Finite State Machine 
for Hello Message Exchange, and 7.2 Hellolnterval, discloses a PeerDeadlnterval, included in 
the FLIP Advertisement, that is at least 3 times the value of the Hellolnterval, which has a 
default value of 3 ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by Comer, to include a time interval that is less than 
one second, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection and expedite the detection and thereby the correction of a failure (Sandick; Abstract 
and Introduction). 
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40. As to Claims 15 and 41, Comer and Sandick in combination disclose each and every 
limitation of claims 12 and 38. Sandick further discloses wherein the status information includes 
a protocol state selected from a group of protocols states consisting of (A) protocol up, (B) 
protocol down, (C) protocol not reporting, and (D) protocol restarting (Sandick; Abstract, 
Introduction, and 4.2 Parameters, discloses that status of the protocol is indicated by the ability 
of the node or the protocol to send messages. A peer protocol receiving the message indicates 
that the protocol state is up, and failure to receive the message indicates the protocol state is 
down). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information, as disclosed by Comer, to include an indication of 
protocol state, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection in IP networks (Sandick; Abstract and Introduction). 

41. As to Claims 20 and 46, Comer discloses each and every limitation of Claims 19 and 45. 
Comer does not explicitly disclose, however Sandick discloses wherein the message further 
includes a first time interval, and wherein the act of updating neighbor node protocol status 
information includes 

i) setting a timer to the first time interval (Sandick; 5.3 Finite State Machine for Hello 
Message Exchange, discloses a setting a PeerDeadlnterval timer to a PeerDeadlnterval); 

ii) starting the timer (Sandick; 5.3 Finite State Machine for Hello Message Exchange, 
discloses a starting the PeerDeadlnterval timer); 
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iii) determining whether or not a further message including protocol status information is 
received from the first node by the second node before the expiration of the timer (Sandick; 5.3 
Finite State Machine for Hello Message Exchange, discloses determining whether or not a 
further hello message including status information is received from the first node before the 
expiration of the timer); and 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by Comer, to include determining whether a further 
message including protocol status information is received before the expiration of a timer, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection (Sandick; 
Abstract and Introduction). 

Comer further discloses iv) if it is determined that a further message including protocol 
status information is not received from the first node by the second node before the expiration of 
the timer, then informing peer protocols of the second node that the at least two protocols of the 
first node are down. (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEP ALIVE Message, discloses informing the BGP and TCP protocols of the second node that 
the BGP and TCP protocols of the first node are down when a timer expires) (Sandick; 5.3 Finite 
State Machine for Hello Message Exchange, discloses informing a peer protocol of the second 
node that the protocol of the first node is down when the timer expires). 

42. As to Claim 21, Comer discloses each and every limitation of Claim 19. Comer does not 
explicitly disclose, however Sandick discloses wherein the status information includes a protocol 
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state selected from a group of protocols states consisting of (A) protocol up, (B) protocol down, 
(C) protocol not reporting, and (D) protocol restarting (Sandick; Abstract, Introduction, and 4.2 
Parameters, discloses that status of the protocol is indicated by the ability of the node or the 
protocol to send messages. A peer protocol receiving the message indicates that the protocol 
state is up, and failure to receive the message indicates the protocol state is down). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information, as disclosed by Comer, to include an indication of 
protocol state, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection in IP networks (Sandick; Abstract and Introduction). 

43. As to Claim 47, Comer and Sandick in combination disclose each and every limitation of 
claim 46. Comer does not explicitly disclose, however Sandick discloses wherein the status 
information includes a protocol state selected from a group of protocols states including at least 
(A) protocol up, (B) protocol down, (C) protocol not reporting, and (D) protocol restarting 
(Sandick; Abstract, Introduction, and 4.2 Parameters, discloses that status of the protocol is 
indicated by the ability of the node or the protocol to send messages. A peer protocol receiving 
the message indicates that the protocol state is up, and failure to receive the message indicates 
the protocol state is down). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information, as disclosed by Comer, to include an indication of 
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protocol state, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection in IP networks (Sandick; Abstract and Introduction). 

44. As to Claim 22, Comer discloses a machine-readable medium having stored thereon a 
machine readable data structure comprising: 

a) an indication, for at least two different protocols of a node, of a state of each of the at 
least two protocols (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEP ALIVE Message, discloses sending a keepalive, with an indication of the state of the BGP 
and TCP protocols, this information is stored in the recipient node in order to determine 
connectivity and verify that the peer protocols still function); and 

Comer does not explicitly disclose, however Sandick discloses b) a dead interval 
(Sandick; 4.2 Parameters and 5.3 Finite State Machine for Hello Message Exchange, discloses 
including a PeerDeadlnterval in the message that is used by the recipient node to determine when 
to declare the peer protocol down) 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include a dead interval, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection in IP 
networks (Sandick; Abstract and Introduction). 

45. As to Claim 23, Comer and Sandick in combination disclose each and every limitation of 
Claim 22. Sandick further discloses wherein the indication indicates a protocol state selected 
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from a group of protocols states consisting of (A) protocol up, (B) protocol down, (C) protocol 
not reporting, and (D) protocol restarting (Sandick; Abstract, Introduction, and 4.2 Parameters, 
discloses that status of the protocol is indicated by the ability of the node or the protocol to send 
messages. A peer protocol receiving the message indicates that the protocol state is up, and 
failure to receive the message indicates the protocol state is down. The peer protocol stores this 
information in order to determine connectivity and verify the peer protocols still function). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include an indication of 
protocol state, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection in IP networks (Sandick; Abstract and Introduction). 

46. As to Claim 24, Comer and Sandick in combination disclose each and every limitation of 
Claim 22. Sandick further discloses c) an identifier of the node (Sandick; 1 .0 Terminology, 5.1 
Protocol Description, 5.2 Hello Message Contents, 5.3 Finite State Machine for Hello Message 
Exchange, discloses including the address of the node in the message that is used by the recipient 
node to determine the status of a particular peer). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include an identifier of the 
node, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection in 
IP networks (Sandick; Abstract and Introduction). 
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47. As to Claim 25, Comer and Sandick in combination disclose each and every limitation of 
Claim 24. Sandick further discloses wherein the node is a router and wherein the identifier is a 
router identifier (Sandick; 1.0 Terminology, 5.1 Protocol Description, 5.2 Hello Message 
Contents, 5.3 Finite State Machine for Hello Message Exchange, discloses including the address 
of the node, which is a router, in the message that is used by the recipient node to determine the 
status of a particular peer). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include an identifier of the 
router, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection 
in IP networks (Sandick; Abstract and Introduction). 

48. As to Claim 26, Comer and Sandick in combination disclose each and every limitation of 
Claim 22. Sandick further discloses c) an interface index (Sandick; Appendix B.l, discloses 
including an interface index in the message that is used by the recipient node to determine the 
interface status of a peer). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include an interface index, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection in IP 
networks (Sandick; Abstract and Introduction). 
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49. Claims 18 and 44 are rejected under 35 U.S.C. 103(a) as being unpatentable over Comer 
and Sandick as applied to claims 13 and 39 above, and further in view of US Patent No. 
5,349,642 issued on September 20, 1994 to Kingdon (hereinafter "Kingdon"). 

50. As to Claims 18 and 44, Comer and Sandick in combination disclose each and every 
limitation of Claims 13 and 39. Comer and Sandick do not explicitly disclose, however Kingdon 
discloses wherein each of the message and the further message include an indication of a relative 
message age, and wherein the act of updating neighbor node protocol status information 
includes, 

iv) if the further message is received then, in addition to resetting the first timer to the new time 
interval and restarting the first timer, further 

A) determining whether the further message is younger than the message, and 

B) if it is determined that the further message is not younger than the message, then 
discarding the further message. 

(Kingdon; Figure 5, discloses determining whether the sequence number of the further received 
message is less than the sequence number of the previously received message and if this is the 
case, discarding the further message). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify updating neighbor node protocol status information, as disclosed by Comer, 
to include consideration of the relative message age, as disclosed by Kingdon, in order to avoid 
accepting older messages that may contain information that is no longer valid. 
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Allowable Subject Matter 

5 1 . Claims 16, 17, 42, and 43 are objected to as being dependent upon a rejected base claim, 
but would be allowable if rewritten in independent form including all of the limitations of the 
base claim and any intervening claims. 

Conclusion 

52. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

53. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 
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Rekhter et al. RFC 1771 - A Border Gateway Protocol 4 (BGP-4): discloses aspects of 
the BGP protocol that are inherent in the protocol. 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to VIVEK KRISHNAN whose telephone number is (571) 270- 
5009. The examiner can normally be reached on Monday through Friday from 9:00 AM to 5:30 
PM EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Jason Cardone can be reached on (571) 272-3933. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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